1. Field of the Invention
The present invention relates to a gateway device having a socket library for monitoring that monitors the communication content in an application; a communication method of a gateway device having a socket library for monitoring; a communication program of a gateway device having a socket library for monitoring; and a socket library for monitoring. The present invention particularly relates to a gateway device having a socket library for monitoring that allows the communication content communicated by a socket in a process to be monitored in other processes; a communication method of a gateway device having a socket library for monitoring; a communication program of a gateway device having a socket library for monitoring; and a socket library for monitoring.
2. Description of the Related Art
There is a method in which a plurality of abnormality detecting applications are integrated to form a gateway device such that a high-performance security gateway is achieved. A representative product is a Unified Threat Management (UTM) that achieves a high-performance security gateway in which are integrated a plurality of functions, such as anti-virus, anti-spam and URL filter functions.
It is of key importance that when a high-performance security gateway device is manufactured, a provider of the device should provide with an Application Program Interface (API) which enables an application developer to readily develop a gateway device. The API is preferably of a more common type, rather than a device-dependent type. Since it is rarely the case that a device provider is also an application developer, employment of a more common-type API allows a device provider and an application developer to develop a product independently of each other. In case where the API provided by the device is not of common type, it is essential that a program should be modified when the device provider uses open source software or third-party applications. However, modification of a program would inevitably involve issues with respect to cost and license, and thus, the integration should preferably conducted with as less modifications as possible.
Further, an application developer can create a more portable program by adjusting a function to a common-type API rather than to a device-dependent API, and thus the development cost is likely to be reduced. An example of a general-purpose API that handles data inputted from a network includes a socket API.
Now, the socket is an interface for an inter-process communication based on the TCP/IP protocol, corresponds to a session layer of an OSI reference model, and is defined between an application layer and a transport layer. A variety of APIs are available as a socket API, details of which are disclosed in the Non-patent Document 1 and so on. Meanwhile, different OSs need different APIs, and thus the configuration of an API slightly differs according to the OS type such as Unix (registered trademark), Linux (registered trademark) and Windows (registered trademark).
Examples of representative API of a socket designed for Unix (trademark registered) include socket( ), bind( ), connect( ), listen( ), accept( ), read( ), write( ) and close( ). To cite an example of a client-server communication using a socket API, a server process creates a socket (socket( ) invocation); assigns an IP address and a port number (bind( ) invocation); and initiates a listen socket outputted from a client process (listen( ) invocation). On the other hand, a client process also creates a socket (socket( ) invocation), and requests a connection to a server process (connect( ) invocation). The server process receives a connection request outputted from a client process (accept( ) invocation), and establishes a connection. Once a connection is established, the client process transmits data to the server process (write( ) invocation). The server process to which data have been transmitted receives the data (read( ) invocation), executes a processing based on the data, and returns the data to the client process (write( ) invocation). The client process receives the data outputted from the server process (read( ) invocation) and executes a processing. After repetition of the request and the response for a while, the client process transmits a connection termination (close( ) invocation), while the server process reads the request (read( ) invocation) to terminate the connection (close( ) invocation).
The advantage of using a socket API when applications are integrated is that both the device developer and the application developer can enjoy the convenience of using the socket API as a well-recognized common-type API. Another advantage of using a socket API for application development is that the data received from the socket can be readily handled as a stream. For example, it is possible to receive and process parts of mail data of 1M bytes (divided by, for instance, 8 k bytes), instead of receiving the entire mail data of 1M bytes and then processing them as a whole. This can avoid the elongated I/O waiting time of the applications until completion of receiving the entire data, thus allowing for efficient execution.
Employment of this socket allows an information processing device storing a plurality of OS's to smoothly perform inter-OS communication without generating unnecessary overhead (Patent Document 1).
Patent Document 2, for example, suggests that in the case of inter-process communication, and not inter-OS communication, an ID is notified by way of socket communication to conduct inter-process communication using a shared memory.
Further, Patent Document 3 suggests an embodiment wherein an I/O operation program is shared by processes operated on each OS, the each OS being separate from each other by means of a partition, and the program being stored in a single information processing device.    [Non-Patent Document 1] Unix (trademark registered) Network Programming, 2nd edition, Vol. 1 Network API: Socket and XTI, W. Richard Stevens, translated by Yoichi Shinoda (Pearson Education)    [Patent Document 1] Japanese Laid-open Patent Publication No. 2006-127461    [Patent Document 2] Japanese Laid-open Patent Publication No. H11-065858    [Patent Document 3] Japanese Patent Application Publication No. 2004-535615
As mentioned above, use of a socket API, which is a versatile and generally-recognized API, will provide cost advantages both for the application developers and for the device developers. However, use of a socket API will involve the following problems when, like a security gateway, communication contents of a single application are shared by a plurality of applications.
The first problem is that one protocol address cannot be bound (bind( )) by a plurality of processes at once. For example, while a process A assigns a protocol address to a socket by bind( ) and executes listen( ), the other process B cannot execute bind( ) using the same protocol address. If bind( ) is invoked, an error is outputted. Hence, a program of the process B describing that a conventional socket API should be used is forced to change.
The second problem is that, due to the above-mentioned first problem, there is no choice but to allow the process B to receive data from the process A by way of inter-process communication in order for the process B to share the communication contents of process A. This demands a change in the program of the process A that the program transmits data to the process B, and a change in the program of the process B that the program receives data from the process A, whereby the program is changed from the original.
The third problem is that, as stated above, the inter-process data transmission and reception results in higher data copying cost. In particular, when one piece of data is shared by n-processes, n-time copies are generated. This problem can be prevented by efficient inter-process communication. Cited Reference 2 discloses an inter-process communication system using a shared memory. However, this system, although provided with an efficient inter-process communication system, fails to solve the first and second problems stated above.
Likewise, Cited References 1 and 3, while disclosing an inter-process communication system, fail to solve the first and second problems stated above. Accordingly, it is clear that none of the Cited References suggest using a socket library that provides with a socket API designed to solve these problems, and using “a gateway device having a socket library for monitoring that monitors the communication content in an application; a communication method of a gateway device having a socket library for monitoring; a communication program of a gateway device having a socket library for monitoring” that solve these problems by way of using the socket library.